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Abstract 

Due to the amount of data that smartphone applications 
can potentially access, platforms enforce permission sys¬ 
tems that allow users to regulate how applications access 
protected resources. If users are asked to make security 
decisions too frequently and in benign situations, they 
may become habituated and approve all future requests 
without regard for the consequences. If they are asked to 
make too few security decisions, they may become con¬ 
cerned that the platform is revealing too much sensitive 
information. To explore this tradeoff, we instrumented 
the Android platform to collect data regarding how of¬ 
ten and under what circumstances smartphone applica¬ 
tions are accessing protected resources regulated by per¬ 
missions. We performed a 36-person field study to ex¬ 
plore the notion of “contextual integrity,” that is, how of¬ 
ten are applications accessing protected resources when 
users are not expecting it? Based on our collection of 27 
million data points and exit interviews with participants, 
we examine the situations in which users would like the 
ability to deny applications access to protected resources. 
We found out that at least 80% of our participants would 
have preferred to prevent at least one permission request, 
and overall, they thought that over a third of requests 
were invasive and desired a mechanism to block them. 


1 Introduction 

Mobile platforms enforce permission models to regulate 
how applications access certain resources, such as users’ 
personal information or sensor data (e.g., camera, GPS, 
etc.). For instance. Android prompts the user during ap¬ 
plication installation with a list of all the abilities that that 
application may use in the future; if the user is uncom¬ 
fortable granting any of these requests, her only option is 
to discontinue installing the application j3|. On iOS, the 
user is prompted at runtime when an application requests 
any one of a handful of data types for the first time, such 
as location, address book contacts, or photos [34) . 


Research has shown that few people read the An¬ 
droid permission requests and even fewer comprehend 
them (16j. Another problem is habituation: on average. 
Android applications present the user with four permis¬ 
sion requests during the installation process G3- While 
iOS users are likely to see far fewer permission requests 
than Android users, because there are fewer possible per¬ 
missions and they are only displayed the first time the 
data is actually requested, it is not clear whether or not 
users are being prompted about access to data that they 
actually find concerning, or whether they would approve 


of subsequent requests 1151. 


Nissenbaum posited that the reason why most privacy 
models fail to predict violations is that they fail to con¬ 


sider contextual integrity 132l|. That is, privacy violations 


occur when personal information is used in ways that 
defy users’ expectations. We believe that this notion of 
“privacy as contextual integrity” can be applied to smart¬ 
phone permission systems to yield more effective per¬ 
missions by only prompting users when an application’s 
access to sensitive data is likely to defy expectations. As 
a first step down this path, we examined how applica¬ 
tions are currently accessing this data and then examined 
whether or not it complied with users’ expectations. 


We modified Android to log whenever an application ac¬ 
cessed a resource that was protected by application per¬ 
missions and then gave these modified smartphones to 36 
participants who used them as their primary phones for 
one week. The purpose of this was to perform dynamic 
analysis to determine how often various applications are 
actually accessing protected resources under realistic cir¬ 
cumstances. Afterwards, subjects returned to the labora¬ 
tory to return the phones and complete exit surveys. We 
showed them various instances over the past week where 
applications had accessed certain types of data and asked 
whether those instances were expected, and whether they 
would have denied access, if given the opportunity. Par¬ 
ticipants stated a desire to block a third of the requests, 
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and that their decision processes were governed by two 
related underlying factors: whether they had privacy con¬ 
cerns surrounding the specific data type and whether they 
understood why the application needed it. 

We contribute the following: 


plications to collect data |25]42). Their level of con¬ 
cern varied from annoyance to seeking retribution when 
presented with possible risks associated with permis¬ 
sions 0 - Some studies employed crowdsourcing to 
create a privacy model based on user expectations 1301. 


• To the best of our knowledge, we performed the first 
field study to quantify the permission usage by third 
party applications under realistic circumstances. 

• We show that our participants wanted to block ac¬ 
cess to protected resources a third of the time. This 
suggests that some requests should be granted by 
runtime consent dialogs, rather than the current all- 
or-nothing install-time approval approach. 

• We model participants’ decisions and show how a 
runtime classifier may be able to determine when to 
confront users with permission decisions. 


Researchers have designed systems to track or reduce 
privacy violations by recommending applications based 
on users’ security concerns ]2| [l2|[T9] |24|[28] |46]j48) . 
Other tools dynamically block runtime permission re¬ 
quests (37). Enck et al. found that a considerable number 
of applications transmitted location or other user data to 
third parties without requiring user consent m- Horny- 
ack et al.’s AppFence system gave users the ability to 
deny data to applications or substitute fake data (24) . 
However, this broke application functionality for one- 
third of the applications tested. 


2 Related Work 

While users are required to approve Android application 
permission requests prior to installation, most users do 
not pay attention to these requests, and fewer fully com¬ 
prehend them [ fl6||26) . In fact, studies have shown that 
even developers are not fully knowledgeable about per¬ 
missions (40) , and are given a lot of freedom when post¬ 
ing an application to the Google Play Store [7|. Appli¬ 
cations often do not follow the principle of least privi¬ 
lege, intentionally or unintentionally (44) . Other work 
has made suggestions on improving the Android per¬ 
mission model with better definitions and hierarchical 
breakdowns (8|. Some researchers have experimented 
with adding fine-grained access control to the Android 
model 0 - Providing users with more privacy informa¬ 
tion and personal examples has been shown to help users 
in choosing applications with fewer permissions 00 


Previous work has examined the overuse of permis¬ 
sions by applications |T3j20), and attempted to iden¬ 
tify malicious applications through their permission re¬ 
quests |36j, or through natural language processing of 
application descriptions (35). Researchers have addition¬ 
ally developed static analysis tools to analyze Android 
permission specifications (6jj9][T3). Felt et al. created a 
permission map through static analysis of many Android 
applications. They found that roughly one-third of their 
tested applications were over-privileged. Our work com¬ 
plements this static analysis by applying dynamic analy¬ 
sis to permission usage. Other dynamic analysis has been 
applied to native (non-Java) APIs among third-party mo¬ 
bile markets (39) , whereas we apply it to the Java APIs 
available to developers in the Google Play Store. 


Researchers examined user privacy expectations sur¬ 
rounding application permissions, and found that users 
were often surprised by the abilities of background ap- 


Reducing the number of security decisions a user must 
make at install-time or run-time is likely to decrease ha¬ 
bituation, and therefore, it is critical to identify which 
security decisions users should be asked to make. Based 
on this theory. Felt et al. created a decision tree to aid 
platform designers in determining the most appropri¬ 
ate permission-granting mechanism for a given resource 
(e.g., access to benign resources should be granted auto¬ 
matically, whereas access to dangerous resources should 
require approval) 0- They concluded that the major¬ 
ity of Android permissions can be automatically granted, 
but 16% (corresponding to the 12 permissions in Table 
[T| should be granted via runtime dialogs. 

Nissenbaum’s theory of contextual integrity can help us 
to analyze “the appropriateness of a flow” in the con¬ 
text of permissions granted to Android applications (32) . 
There is ambiguity in defining when an application actu¬ 
ally needs access to user data to run properly. It is quite 
easy to see why a location-sharing application would 
need access to GPS data, whereas that same request com¬ 
ing from a game like Angry Birds is less obvious. “Con¬ 
textual integrity is preserved if information flows accord¬ 
ing to contextual norms” (32) , however, the lack of thor¬ 
ough documentation on the Android permission model 
makes it easier for programmers to neglect these norms, 
whether intentionally or accidentally (38) . Deciding on 
whether an application is violating users’ privacy can be 
quite complicated since “the scope of privacy is wide- 
ranging” |32j]. To that end, we performed dynamic analy¬ 
sis to measure how often (and under what circumstances) 
applications were accessing protected resources, whether 
this complied with users’ expectations, as well as how 
often they might be prompted if we adopt Felt et al.’s 
proposal to require runtime user confirmation before ac¬ 
cessing a subset of these resources 0 - 
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3 Methodology 

Our long-term research goal is to minimize habituation 
by only confronting users with necessary security de¬ 
cisions by not showing them permission requests that 
are either expected, reversible, or unconcerning. In this 
study, we explored the problem space in two parts: we 
instrumented Android so that we could collect actual us¬ 
age data to understand how often access to various pro¬ 
tected resources is requested by applications in practice, 
and then we surveyed our participants to understand the 
requests that they would not have granted, if given the 
option. This field study involved 36 participants over the 
course of one week of normal smartphone usage. In this 
section, we describe the log data that we collected, our 
recruitment procedure, and then our exit survey. 

3.1 Tracking Access to Sensitive Data 

In Android, when applications attempt to access pro¬ 
tected resources (e.g., personal information, sensor data, 
etc.), the operating system checks to see whether or 
not the requesting application has been granted permis¬ 
sion. We modified the Android platform to add a logging 
framework so that we could determine every time one of 
these resources was accessed by an application. Because 
our target device was a Samsung Nexus S smartphone, 
we modified Android 4.1.1 (Jellybean), which was the 
newest version of Android supported by our hardware. 

3.1.1 Data Collection Architecture 

Our goal was to collect as much data as possible 
surrounding each applications’ access to protected re¬ 
sources, while minimizing our impact on system perfor¬ 
mance. Our data collection framework consisted of two 
main components: a series of “producers” that hooked 
various Android API calls and a “consumer” embedded 
in the main Android framework service that wrote the 
data to a log file and uploaded it to our collection server. 

We logged three kinds of permission requests. First, we 
logged function calls checked by checkPermissionO 
in the Android Context implementation. Instru¬ 
menting the Context implementation, instead of the 
ActivityManagerService or PackageManager, al¬ 
lowed us to also log the function name invoked by the 
user-space application. Next, we logged access to the 
ContentProvider class, which verifies the read and 
write permissions of an application prior to it accessing 
structured data (e.g., contacts or calendars) 0 - Finally, 
we tracked permission checks during Intent transmis¬ 
sion, by instrumenting the ActivityManagerService 
and BroadcastQueue. Intents allow an application to 
pass messages to another application when an activity is 
to be performed in that other application (e.g., opening a 
URL in the web browser) ©• 


We created a component called Producer, which fetches 
the data from the above instrumented points and sends it 
back to the Consumer, which is responsible for logging 
everything reported. Producers are scattered across 
the Android Platform, since permission checks occur in 
multiple places. We placed the Producer that fetched 
the most data in system_server, which recorded direct 
function calls to Android’s Java API. For a majority of 
privileged function calls, when a user application invokes 
the function, it sends the request to system_server 
via Binder. Binder is the most prominent IPC mech¬ 
anism implemented to communicate with the Android 
Platform (whereas Intents communicate between ap¬ 
plications). For requests that do not make IPC calls to the 
system_server, a Producer is placed in the user appli¬ 
cation context (e.g., in the case of ContentProviders). 


The Consumer class is responsible for logging data 
produced by each Producer. Apart from this, the 
Consumer also stores contextual information alongside 
the permission details. More details on the contextual 
data is given in Section 3.1.2| The Consumer syncs data 
with the filesystem periodically to minimize impact on 
system performance. All log data is written to the inter¬ 
nal storage of the Android Phone because the Android 
kernel is not allowed to write to external storage for se¬ 
curity reasons. Although this protects our data from cu¬ 
rious or careless users, it also limits our storage capacity. 
Thus, we compressed the log files once every two hours 
and upload them to our collection servers whenever the 
phone had an active Internet connection (the average up¬ 
loaded and zipped log file was around 108 KB and con¬ 
tained 9,000 events). 


Due to the high volume of permission checks we encoun¬ 
tered and our goal of keeping system performance at ac¬ 
ceptable levels, we added logic so that the Consumer can 
rate-limit itself. Specifically, if it has logged permission 
checks for a particular application/permission combina¬ 
tion more than 10,000 times, it examines whether it did 
so while exceeding an average rate of 1 permission check 
every 2 seconds. If so, the Consumer will only record 
10% of all future requests for this application/permission 
combination. When this rate-limiting is enabled, the 
Consumer tracks these application/permission combina¬ 
tions and updates all the Producers so that they start 
dropping these log entries. Finally, the Consumer makes 
a note of whenever this occurs so that we can extrapolate 
the true number of permission checks that occurred. 


3.1.2 Data Collection 

We hooked the permission-checking APIs so that every 
time system code was called to check whether an applica¬ 
tion had been granted a particular permission, we logged 
the name of the permission being checked, the name of 
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the calling application, the API method that resulted in 
the permission check, and various contextual data. Re¬ 
call that permission checks not only occur when certain 
protected API methods are called, but also when pro¬ 
tected Intents and ContentProviders are accessed. 
Thus, our logs differentiate between these three ways of 
accessing protected resources. 

With regard to contextual data, in addition to timestamps, 
we collected the following types of data: 

• Visibility —Whether the requesting application was 
visible to the user or not, which we categorized into 
four sub-categories: the application was running (a) 
as a service with no visibility to the user; (b) as a 
service, but interacted with the user via notifications 
or sounds; (c) as a foreground process, but was in 
the background due to multitasking; or (d) as a fore¬ 
ground process with which the user was interacting. 

• Screen Status —Whether the screen was on/off. 

• Connectivity —Whether the phone was connected 
to a WiFi network. 

• Location —The user’s last known coordinates. In 
order to preserve battery life, we collected cached 
location data, rather than directly querying the GPS. 

• View —The UI elements in the requesting applica¬ 
tion that were exposed to the user at the time that a 
protected resource was accessed. Specifically, since 
the UI is built from an XML file, we recorded the 
name of the screen as defined in the DOM. 

• History —A list of applications with which the user 
interacted prior to the requesting application. 

• Path —When access to a ContentProvider object 
was requested, the path to the specific content (e.g., 
photos, contacts, etc.). 

Felt et al. proposed that most Android permissions 
should require no a priori user approval, but 12 permis¬ 
sions (Table[Ij) should be granted at runtime so that users 
have contextual information to infer why the data might 
be needed Specifically, if the user is asked to grant 
a permission while using an application, she may have 
some understanding of why the application needs that 
permission based on what she was doing. We initially 
wanted to perform experience sampling by probabilisti¬ 
cally questioning participants whenever any of these 12 
permissions were checked (29). Our goal was to sur¬ 
vey participants about whether access to these resources 
was expected and whether it should proceed, but we were 
concerned that this would prime them to the security fo¬ 
cus of our experiment, biasing their subsequent behav¬ 
iors. Instead, we instrumented the phones to probabilis¬ 
tically take screenshots of what participants were do¬ 
ing when these 12 permissions were checked so that we 
could ask them about it during the exit survey. We used 


Permission Type 

Activity 

WRITE_SYNC_ 

SETTINGS 

Change sync settings for an appli¬ 
cation when the user is roaming 

ACCESS_WIFI_ 

STATE 

View nearby SSIDs 

INTERNET 

Access Internet when the user is 
roaming 

NFC 

Communicate via NFC 

READ-HISTORY- 

BOOKMARKS 

Read users’ browser history 

ACCESSJTNE_ 
LOCATION 

Read the GPS location 

ACCESS_COARSE_ 

LOCATION 

Read the network-inferred loca¬ 
tion (i.e., cell tower and/or WiFi) 

LOCATION^ 

HARDWARE 

Directly access GPS data 

READ CALL LOG 

Read call history 

ADD_VOICEMAIL 

Read call history 

READ_SMS 

Read sent/received/draft SMS 

SEND-SMS 

Send SMS 


Table 1: The 12 permissions that Felt et al. recommend 
be granted via runtime dialogs 1141. We randomly took 
screenshots when these permissions were requested by 
applications, and we asked about them in our exit survey. 


reservoir sampling to minimize storage and performance 
impacts, while also ensuring that the screenshots covered 
a broad set of applications and permissions (43). 

Figure [T] shows an example screenshot captured during 
the study along with its corresponding log entry. The 
user was playing the Solitaire game while Spotify re¬ 
quested a WiFi scan. Since this function was of interest 
(Table [TJ, our instrumentation took a screenshot. Since 
Spotify was not the application the participant was inter¬ 
acting with, its visibility is set to false. The history shows 
that prior to Spotify calling getScanResultsO, the 
user had viewed Solitaire, the call screen, the launcher, 
and the list of MMS conversations. 

3.2 Recruitment 

We placed an online recruitment advertisement on 
Craigslist in October of 2014, under the “et cetera jobs” 
section]]] The title of the advertisement was “Research 
Study on Android Smartphones,” and it stated that the 
study was about how people interact with their smart¬ 
phones. We made no mention of security or privacy. 
Those interested in participating were directed to an on¬ 
line consent form. Upon agreeing to the consent form, 
potential participants were directed to a screening appli¬ 
cation in the Google Play store. The screening applica- 

1 Approved by our IRB under protocol #2013-02-4992 
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(a) Screenshot 


Name 

Log Data 

Type 

API_FUNC 

Permission 

ACCESS WIFT STATE 

AppJSfame 

com.spotify.music 

Timestamp 

1412888326273 

API Function 

getScanResultsf) 

Visibility 

FALSE 

Screen Status 

SCREEN ON 

Connectivity 

N OT .CONNECTED 

Location 

Lat 37.8735436 Long -122.2992491 - 
1412538686641 (Time it was updated) 

View 

com. mobility ware. solitaire/. Solitaire 

History 

com.android.phone/.lnCallScreen 

com.android.launcher/com.android.- 

launcher2.Launcher 

com. android. mms/Conversationl.i st 

Path 

N/A 

Screenshot 

898448929 


(b) Corresponding log entry 


Figure 1: Screenshot (a) and corresponding log entry (b) 
captured during the experiment. 

tion asked for information about each potential partici¬ 
pant’s age, gender, smartphone make and model. It also 
collected data on their phones’ internal memory size and 
the installed applications. We screened out applicants 
who were under 18 years of age or used providers other 
than T-Mobile, since our experimental phones could not 
attain 3G speeds on other providers. We collected data 
on participants’ installed applications so that we could 
pre-install their free applications on our experimental 
phones, prior to them visiting our laboratory. (We copied 
their paid applications from their phones, since we could 
not download those from Google Play ahead of time.) 

We contacted participants who met our screening re¬ 
quirements by email to schedule a time for them to come 
and visit us to do the initial setup. Overall, 48 people 
showed up to our laboratory, and out of those 48 people. 


40 qualified (8 had to be rejected because our screening 
application was unable to distinguish some Metro PCS 
users from T-Mobile users). In the email we noted that 
due to the space constraints of our experimental phones, 
we might not be able to install all the applications present 
on their existing phones, and therefore they needed to 
make a note of the ones that they planned to use during 
the next week. The initial setup took roughly 30 minutes 
and involved installing their existing SIM cards into our 
experimental phones, helping them set up their Google 
and other accounts, and making sure they had all the ap¬ 
plications needed for the coming week. We immediately 
compensated each participant with a $35 gift card for 
showing up at the setup session. Out of 40 people who 
were given phones, 2 did not return the phones, and 2 
did not regularly use the phones during the study period. 
Of our 36 remaining participants who used the phones 
regularly, 19 were male and 17 were female; ages ranged 
from 20 to 63 years old (fx = 32, a= 11). 

After the initial setup session, participants used the ex¬ 
perimental phones for one week in lieu of their normal 
phones. They were allowed to install and uninstall appli¬ 
cations, and we instructed them to use these phones as 
they would their normal phones. Our logging framework 
kept track of every protected resource accessed by a user- 
level application along with the previously-mentioned 
contextual data. Due to storage constraints on the de¬ 
vices, our software uploaded log files to our server every 
two hours. However, to preserve participants’ privacy, 
screenshots remained on the phones during the course 
of the week. At the end of the week, each participant 
returned to our laboratory, completed an exit survey, re¬ 
turned the phone, and then received an additional $100 
gift card for completing the study. 

3.3 Exit Survey 

When participants returned to our laboratory, they com¬ 
pleted an exit survey. The exit survey software ran on 
a laptop in a private room so that it could ask questions 
about what they were doing on their phones during the 
course of the week without raising privacy concerns. We 
did not view their screenshots until participants gave us 
permission. The survey had three components: 

• Screenshots —Our software displayed a screenshot 
taken during the course of the week when one of the 
12 resources in Table Q] was accessed. Next to the 
screenshot (Figure [2a]), we asked participants what 
they were doing on the phone when the screenshot 
was taken (open-ended). We also asked them to in¬ 
dicate which of several actions they believed the ap¬ 
plication was performing, chosen from a multiple- 
choice list of permissions presented in plain lan¬ 
guage (e.g., “reading browser history,” “sending a 
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SMS,” etc.)- After answering these two questions, 
they proceeded to a second page of questions (Fig¬ 
ure [2b]). We informed participants at the top of this 
page of the resource that the application had ac¬ 
cessed when the screenshot was taken, and asked 
them to indicate how much they expected this using 
a 5-point Likert scale. Next, we asked, “if you were 
given the choice, would you have prevented the app 
from accessing this data,” and to explain why or 
why not. Finally, we asked for permission to view 
that particular screenshot. This phase of the exit 
survey was repeated for 10-15 different screenshots 
per participant, based on the number of screenshots 
saved by our reservoir sampling algorithm. 

• Locked Screens —The second part of our survey 
involved questions about the same protected re¬ 
sources, however, this time these resources were 
accessed while device screens were off (i.e., when 
participants were not actively using their phones). 
Because there were no contextual cues (i.e., screen- 
shots), we outright told participants which appli¬ 
cations were accessing which resources and asked 
them multiple choice questions about whether they 
wanted to prevent this and the degree to which these 
behaviors were expected. They answered these two 
questions for up to 10 different requests, similarly 
chosen by our reservoir sampling algorithm to yield 
a breadth of application/permission combinations. 

• Personal Privacy Preferences —Finally, in order 
to correlate participants’ responses with their per¬ 
sonal privacy preferences, they completed two pri¬ 
vacy scales. Because of the numerous reliability 
problems with the often cited Westin index [:45j, 
participants completed both Buchanan et al.’s Pri¬ 
vacy Concerns Scale (PCS) m and Malhotra et 
al.’s Internet Users’ Information Privacy Concerns 
(IUIPC) scale J3l) . We compared the average 
scores of both scales. 

After completing the exit survey, we re-entered the room, 
answered any remaining questions about the experiment, 
and then assisted the participant in transferring her SIM 
card back into her personal phone. Finally, we compen¬ 
sated each participant with a $100 gift card. 

Three researchers independently coded 423 responses to 
the open-ended question from the screenshot portion of 
the survey. The number of responses per participant var¬ 
ied, as they were randomly selected based on the num¬ 
ber of screenshots taken by their phones. Participants 
who used their phones more heavily had more screen- 
shots, and thus answered more questions. Prior to meet¬ 
ing to achieve consensus, the three coders disagreed on 
the coding of 42 responses, which equated to an inter¬ 
rater agreement of 90%. We used Fleiss’ kappa to assess 



(a) On the first screen, participants answered questions to estab¬ 
lish awareness of the permission request based on the screenshot. 



(b) On the second screen, they saw the resource accessed, stated 
whether it was expected, and whether it should have been blocked. 

Figure 2: Exit Survey Interface 


the reliability of ratings, taking into account the 9 possi¬ 
ble codings for each response. The process resulted in a 
kappa of 0.61, which indicates substantial agreement. 

4 Application Behaviors 

During the week that participants used our instrumented 
phones, we logged 27M requests by applications to pro¬ 
tected resources (i.e., those governed by Android per¬ 
missions). This translates to over one hundred thousand 
requests per user per day. In this section, we quantify 
the circumstances under which these resources were ac¬ 
cessed. We focus on the rate at which applications re¬ 
quested access to protected resources when participants 
were not actively using those applications (i.e., the situa¬ 
tions that likely defy users’ expectations), access to cer¬ 
tain resources with particularly high frequency, and the 
impact of replacing certain requests with runtime confir¬ 
mation dialogs (as per Felt et al.’s suggestion ID)- 
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4.1 Invisible Permission Requests 

In many cases, it is entirely expected that an applica¬ 
tion might make frequent requests to resources protected 
by permissions. For instance, the INTERNET permis¬ 
sion is used every time an application needs to open a 
socket, ACCESS_FINE_LOCATION is used every time 
the user’s location is checked by a mapping application, 
and so on. However, in these cases, one expects users to 
have certain contextual cues to help them understand that 
these applications are running and making these requests. 
Based on our log data, most requests occurred while par¬ 
ticipants were not actually interacting with those appli¬ 
cations, nor did they have any cues to indicate that the 
applications were even running. When resources are ac¬ 
cessed, applications can be in five different states, with 
regard to their visibility to users: 

1. Visible foreground application (12.04%): the user 
is using the application requesting the resource. 

2. Invisible background application (0.70%): due to 
multitasking, the application is in the background. 

3. Visible background service (12.86%); the appli¬ 
cation is a background service, but the user may be 
aware of its presence due to other cues (e.g., it is 
playing music or is present in the notification bar). 

4. Invisible background service (14.40%); the appli¬ 
cation is a background service without visibility. 

5. Screen off (60.00%): the application is running, 
but the phone screen is off because it is not in use. 

Combining the 3.3M (12.04% of 27M) requests that were 
granted when the user was actively using the application 
(Category 1) with the 3.5M (12.86% of 27M) requests 
that were granted when the user had other contextual 
cues to indicate that the application was running (Cat¬ 
egory 3), we can see that fewer than one quarter of all 
permission requests (24.9% of 27M) occurred when the 
user had clear indications that those applications were 
running. This suggests that during the vast majority of 
the time, access to protected resources occurs opaquely 
to users. We focus on these 20.3M “invisible” requests 
(75.1% of 27M) in the remainder of this subsection. 

Harbach et al. found that users’ phone screens are off 
94% of the time on average |22 1. We observed that 
60% of permission requests occurred while participants’ 
phone screens were off, which suggests that permission 
requests occurred less frequently than when participants 
were using their phones. At the same time, certain appli¬ 
cations made more requests when participants were not 
using their phones: “Brave Frontier Service,” “Microsoft 
Sky Drive,” and “Tile game by UMoni.” Our study col¬ 
lected data on over 300 applications, and therefore it is 
possible that with a larger sample size, we would ob¬ 
serve other applications engaging in this behavior. All of 


Permission 

Requests 

ACCES S _NETWORK_STATE 

31,206 

WAKE_LOCK 

23,816 

ACCESS_FINE_LOCATION 

5,652 

GET .ACCOUNT S 

3,411 

ACCESS WIFI STATE 

1,826 

UPDATE _DEVICE_STATS 

1,426 

ACCES S _COARSE_LOC ATION 

1,277 

AUTHENTICATEWCCOUNTS 

644 

READ _S YN C _S ETTINGS 

426 

INTERNET 

416 


Table 2: The most frequently requested permissions by 
applications with zero visibility to the user. 


Application 

Requests 

Facebook 

36,346 

Google Location Reporting 

31,747 

Facebook Messenger 

22,008 

Taptu DJ 

10,662 

Google Maps 

5,483 

Google Gapps 

4,472 

Foursquare 

3,527 

Yahoo Weather 

2,659 

Devexpert Weather 

2,567 

Tile Game(Umoni) 

2,239 


Table 3: The applications making the most permission 
requests while running invisibly to the user. 

the aforementioned applications primarily requested AC- 
CESS_WIFI_STATE and INTERNET. While a definitive 
explanation for this behavior requires examining source 
code or the call stacks of these applications, we hypothe¬ 
size that they were continuously updating local data from 
remote servers. For instance. Sky Drive may have been 
updating documents, whereas the other two applications 
may have been checking the status of multiplayer games. 

Table [2] shows the most frequently requested permis¬ 
sions from applications running invisibly to the user (i.e., 
Categories 2, 4, and 5); Table [3] shows the applica¬ 
tions responsible for these requests (Appendix [C] lists 
the permissions requested by these applications). We 
normalized the numbers to show requests per user/day. 
ACCESS_NETWORK_STATE was most frequently re¬ 
quested, averaging 31,206 times per user/day—roughly 
once every 3 seconds. This is due to applications con¬ 
stantly checking for Internet connectivity. However, the 
5,562 requests/day to ACCESS_FINE_LOCATION and 
1,277 requests/day to ACCES S _COA R S E_LOC A'l’ION 
are more concerning, as this could enable detailed track¬ 
ing of the user’s movement throughout the day. Sim¬ 
ilarly, a user’s location can be inferred by using AC- 
CESS_WIFI_STATE to get data on nearby WiFi SSIDs. 
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Contextual integrity means ensuring that information 
flows are appropriate, as determined by the user. Thus, 
users need the ability to see information flows. Current 
mobile platforms have done some work to let the user 
know about location tracking. For instance, recent ver¬ 
sions of Android allow users to see which applications 
have used location data recently. While attribution is a 
positive step towards contextual integrity, attribution is 
most beneficial for actions that are reversible, whereas 
the disclosure of location information is not something 
that can be undone 03- We observed that fewer than 
1% of location requests were made when the applica¬ 
tions were visible to the user or resulted in the display¬ 
ing of a GPS notification icon. Given that Thompson et 
al. showed that most users do not understand that appli¬ 
cations running in the background may have the same 
abilities as applications running in the foreground |42) , 
it is likely that in the vast majority of cases, users do not 
know when their locations are being disclosed. 

This low visibility rate is because Android only shows a 
notification icon when the GPS sensor is accessed, while 
offering alternative ways of inferring location. In 66.1% 
of applications’ location requests, they directly queried 
the TelephonyManager, which can be used to deter¬ 
mine location via cellular tower information. In 33.3% 
of the cases, applications requested the SSIDs of nearby 
WiFi networks. In the remaining 0.6% of cases, applica¬ 
tions accessed location information using one of three 
built-in location providers: GPS, network, or passive. 
Applications accessed the GPS location provider only 
6% of the time (which displayed a GPS notification). 
In the other 94% of the time, 13% queried the network 
provider (i.e., approximate location based on nearby cel¬ 
lular towers and WiFi SSIDs) and 81% queried the pas¬ 
sive location provider. The passive location provider 
caches prior requests made to either the GPS or network 
providers. Thus, across all requests for location data, the 
GPS notification icon appeared 0.04% of the time. 

While the alternatives to querying the GPS are less ac¬ 
curate, users are still surprised by their accuracy ED- 
This suggests a serious violation of contextual integrity, 
since users likely have no idea their locations are being 
requested in the vast majority of cases. Thus, runtime no¬ 
tifications for location tracking need to be improved (18). 

Apart from these invisible location requests, we also ob¬ 
served applications reading stored SMS messages (125 
times per user/day), reading browser history (5 times per 
user/day), and accessing the camera (once per user/day). 
Though the use of these permission does not necessarily 
lead to privacy violations, users have no contextual cues 
to understand that these requests are occurring. 


Application / Permission 

Peak (ms) 

Avg. (ms) 

com.facebook.katana 

213.88 

956.97 

ACCESS_NETWORK_STATE 

com.facebook.orca 

334.78 

1146.05 

ACCESS-NETWORK-STATE 

com. google. android, apps .maps 

247.89 

624.61 

ACCESS-NETWORK-STATE 

com.google.process.gapps 

315.31 

315.31 

AUTHENTICATE_ACCOUNTS 

com.google.process.gapps 

898.94 

1400.20 

WAKE _LOCK 

com.google.process.location 

176.11 

991.46 

WAKE _LOCK 

com.google.process.location 

1387.26 

1387.26 

ACCESS_FINE_LOCATION 

com.google.process.location 

373.41 

1878.88 

GET_ACCOUNTS 

com.google.process.location 

1901.91 

1901.91 

ACCESS-WIFLSTATE 

com.king.farmheroessaga 

284.02 

731.27 

ACCESS-NETWORK-STATE 

com.pandora.android 

541.37 

541.37 

ACCESS-NETWORK-STATE 

com. taptu. streams 

1746.36 

1746.36 

ACCESS_NETWORK_STATE 


Table 4: The application/permission combinations that 
needed to be rate limited during the study. The last two 
columns show the fastest interval recorded and the aver¬ 
age of all the intervals recorded before rate-limiting. 


4.2 High Frequency Requests 

Some permission requests occurred so frequently that a 
few applications (i.e., Facebook, Facebook Messenger, 
Google Location Reporting, Google Maps, Farm Heroes 
Saga) had to be rate limited in our log files, so that the 
logs would not fill up users’ remaining storage or incur 
performance overhead. Our software probabilistically 
began dropping log entries if during an application’s pre¬ 
vious 10,000 requests for a particular permission, the av¬ 
erage interval between requests was less than 2 seconds. 
Table[4]shows the complete list of application/permission 
combinations that exceeded this threshold. For instance, 
the most frequent requests came from Facebook request¬ 
ing ACCESS-NETWORK-STATE with an average inter¬ 
val of 213.88 ms (i.e., almost 5 times per second). 

With the exception of Google’s applications, all rate- 
limited applications made excessive requests for the 
phone’s connectivity state. Our hypothesis is that once 
these applications lose connectivity, they continuously 
poll the system until access is regained. All of these 
applications’ use of the getActiveNetworklnfoO 
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Resource 

Visibl 

Data Exposed 

e 

Requests 

Invisib 

Data Exposed 

le 

Requests 

Total 

Data Exposed 

Requests 

Location 

758 

2,205 

3,881 

8,755 

4,639 

10,960 

Read SMS data 

378 

486 

72 

125 

450 

611 

Sending SMS 

7 

7 

1 

1 

8 

8 

Browser History 

12 

14 

2 

5 

14 

19 

Total 

1,155 

2,712 

3,956 

8,886 

5,111 

11,598 


Table 5: The sensitive permission requests (per user/day) when requesting applications were visible/invisible to users. 
“Data exposed” reflects the subset of permission-protected requests that resulted in sensitive data being accessed. 


method resulted in these permission checks, which re¬ 
turns a Networklnfo object. This object allows devel¬ 
opers to determine connection state (e.g., connected, dis¬ 
connected, etc.) and type (e.g., WiFi, Bluetooth, cellu¬ 
lar, etc.). Thus, these requests do not appear to be leak¬ 
ing sensitive information per se, but their frequency may 
have an adverse effect on performance and battery life. 
It is possible that using the ConnectivityManager’s 
NetworkCallback method may be able to fulfill this 
need with far fewer permission checks. 

4.3 Feasibility of Runtime Requests 

Felt et al. posited that while most application permissions 
can be granted automatically in order to not habituate 
users to relatively benign risks, certain permissions re¬ 
quests should require runtime consent 0- They advo¬ 
cated using runtime dialogs before the following abili¬ 
ties, observed during our study, should proceed: 

1. Reading the user’s location information, which in¬ 
cludes using a conventional location API or scan¬ 
ning for nearby WiFi SSIDs. 

2. Reading the user’s web browser history. 

3. Reading saved SMS messages. 

4. Sending SMS messages that incur charges, or inap¬ 
propriately spamming the user’s contact list. 

These four resources/abilities are governed by the 12 
Android permissions listed in Table [T] Of the 300 ap¬ 
plications that we observed during the experiment, 91 
(30.3%) performed one of these abilities during the study 
period. On average, these permissions were requested 
213 times per hour per user—roughly every 20 seconds. 
However, permission checks occur under a variety of cir¬ 
cumstances, only a subset of which allow applications 
access to sensitive resources. As a result, platform de¬ 
velopers may decide to only show runtime warnings to 
users when protected data is read or modified. Thus, 
we attempted to quantify the frequency with which per¬ 
mission checks actually result in access to sensitive re¬ 
sources for each of these four categories. Table[5]shows 
the number of requests seen per user/day under each of 
these four categories, separating the instances in which 


sensitive data was exposed from the total permission re¬ 
quests observed. Unlike Section 4.1 we include “visi¬ 
ble” permission requests (i.e., those occurring while the 
user was actively using the application or had other con¬ 
textual information to indicate it was running). 


Of the location permission checks, a majority were 
due to requests for location provider information 
(e.g., getBestProvider () returns the best location 
provider based on application requirements), or check¬ 
ing WiFi state (e.g., getWifiStateO only reveals 
whether WiFi is enabled). Only a portion of the 
requests actually exposed participants’ locations (e.g., 
getLastKnownLocationO or getScanResults() 
exposed SSIDs of nearby WiFi networks). 

Although a majority of requests for the READ_SMS per¬ 
mission exposed content in the SMS store (e.g., Query () 
reads the contents of the SMS store), a considerable por¬ 
tion simply read information about the SMS store (e.g., 
renewMmsConnectivity () resets an applications’ con¬ 
nection to the MMS store). An exception to this is the use 
of SEND_SMS, which resulted in the transmission of an 
SMS message every time the permission was requested. 


Regarding browser history, both accessing visited URLs 
(getAHVisitedUrlsO) and reorganizing bookmark 
folders (addFolderToCurrent ()) result in the same 
permission being checked. However, the latter does not 
expose specific URLs to the invoking application. 


Based on our analysis of the API methods that resulted in 
permission checks, we observed that sensitive data was 
only exposed to applications during half of these permis¬ 
sion checks, on average. For instance, across both visible 
and invisible application requests, 5,111 of the 11,598 
(44.3%) permission checks involving the 12 permissions 
in Table [T] resulted in sensitive data being exposed to 
those applications (Table[5j. 

While narrowing runtime permission requests down to 
only the cases in which sensitive resources are being ac¬ 
cessed will greatly decrease the number of times users 
will be interrupted, the frequency with which these re¬ 
quests occur is still too great to reasonably prompt the 
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user each time a request occurs. We also do not believe 
that the iOS model of only prompting on the first request 
is appropriate, because our data shows that in the vast 
majority of cases when protected resources are accessed, 
the user has no contextual cues to understand that it is 
occurring. Thus, a user may grant a request the first time 
an application asks, because it is appropriate in that in¬ 
stance, but then the user may be surprised to find that the 
application continues to access the resource in other con¬ 
texts (e.g., when the user is not using the application). As 
a result, a more intelligent method is needed to determine 
when a given permission request is likely to be deemed 
appropriate by the user. 

5 User Expectations and Reactions 

To examine when users might want to be prompted about 
permission requests at runtime, our exit survey focused 
on participants’ reactions to the 12 permissions in Table 
|T| as well as limiting the number of requests shown to 
each participant based on our reservoir sampling algo¬ 
rithm, which was designed to ask participants about a di¬ 
verse set of permission/application combinations. Thus, 
we collected participants’ reactions to 673 permission 
requests (« 19 per participant). Of these requests, 423 
were accompanied by screenshots because participants 
were actively using their phones when the resources were 
accessed, whereas 250 permission requests were per¬ 
formed while device screens were ofijj Of the former, 
243 screenshots were taken while the requesting appli¬ 
cation was visible in the foreground, whereas 180 were 
taken while the application was invisible in the back¬ 
ground. In this section, we describe the situations in 
which permission requests defied users’ expectations. 
We present explanations for why participants wanted to 
block certain permission requests, the factors influenc¬ 
ing those decisions, and how expectations changed when 
devices were not actively in use. 

5.1 Reasons for Blocking 

When viewing screenshots of what they were doing 
when an application requested a permission, 30 partic¬ 
ipants (80% of 36) stated that they would have preferred 
to block at least one request, whereas 6 stated a willing¬ 
ness to allow all requests, regardless of resource type or 
application. Across the entire study, participants wanted 
to block 35% of these 423 permission requests. When we 
asked participants to explain their rationales for these de¬ 
cisions, two main themes emerged: the request did not— 
in their minds—pertain to application functionality or it 
involved information they were uncomfortable sharing. 

2 Our first 11 participants did not answer questions about permission 
requests occurring while not using their devices, and therefore the data 
only corresponds to our last 25 participants. 


5.1.1 Relevance to Application Functionality 

When prompted for the reason behind blocking a permis¬ 
sion request, 19 (53% of 36) participants did not believe 
it was necessary for the application to perform its task. 
Of the 149 (35% of 423) requests that participants would 
have preferred to block, 79 (53%) were perceived as be¬ 
ing irrelevant to the functionality of the application: 

• “It wasn’t doing anything that needed my current 
location." (PI) 

• “I don’t understand why this app would do anything 
with SMS.” (P10) 

• “I don’t know why my alarm clock needs to know 
where I am.” (P8) 

Accordingly, functionality was the most common reason 
for wanting a permission request to proceed. Out of the 
274 permissible requests, 195 (71% of 274) were per¬ 
ceived as necessary for the core functionality of the ap¬ 
plication. Thirty-one (86% of 36) participants mentioned 
perceived functional necessities as a reason for allowing 
at least one permission request to proceed: 

• “Because it’s a weather app and it needs to 
know where you are to give you weather informa¬ 
tion .”(P13) 

• “I think it needs to read the SMS to keep track of the 
chat conversation ”(P12) 

Beyond being necessary for core functionality, partici¬ 
pants wanted 10% (27 of 274) of requests to proceed be¬ 
cause they offered convenience; 90% of these requests 
were for location data, and the majority of those appli¬ 
cations were published under the Weather, Social, and 
Travel & Local categories in the Google Play store: 

• “It selects the closest stop to me so I don’t have to 
scroll through the whole list." (P0) 

• “This app should read my current location. I’d like 
for it to, so I won’t have to manually enter in my zip 
code / area.” (P4) 

Thus, requests were allowed when they were expected: 
when participants rated the extent to which each request 
was expected on a 5-point Likert scale, allowable re¬ 
quests averaged 3.2, whereas blocked requests averaged 
2.3 (lower is less expected). 

5.1.2 Privacy Concerns 

Participants also wanted to deny permission requests that 
involved data that they considered sensitive, regardless 
of whether they believed the application actually needed 
the data to function. Nineteen (53% of 36) participants 
noted privacy as a concern while blocking a request, and 
of the 149 requests that participants wanted to block, 49 
(32% of 149) requests were blocked for this reason: 
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• “SMS messages are quite personal.” (P14) 

• “It is part of a personal conversation.” (PI 1) 

• “Pictures could be very private and I wouldn’t like 
for anybody to have access.” (P16) 

Conversely, 24 participants (66% of 36) wanted requests 
to proceed simply because they did not believe that the 
data involved was particularly sensitive; this reasoning 
accounted for 21% of the 274 allowable requests: 

• “I’m ok with my location being recorded, no con¬ 
cerns.” (P3) 

• “No personal info being shared.” (P29) 

5.2 Influential Factors 

Based on participants’ responses to the 423 permission 
requests involving screenshots (i.e., requests occurring 
while they were actively using their phones), we quan¬ 
titatively examined how various factors influenced their 
desire to block some of these requests. 

Effects of Identifying Permissions on Blocking: In the 

exit survey, we asked participants to guess the permis¬ 
sion an application was requesting, based on the screen- 
shot of what they were doing at the time. The real an¬ 
swer was among four other incorrect answers. Of the 
149 cases where participants wanted to block permission 
requests, they were only able to correctly state what per¬ 
mission was being requested 24% of the time; whereas 
when wanting a request to proceed, they correctly iden¬ 
tified the requested permission 44% (of 274) of the time. 
However, Pearson’s product-moment tes0did not yield a 
statistically significant correlation (r=-0.171, p<0.317). 

Effects of Visibility on Expectations: We were par¬ 
ticularly interested in exploring if a permission request 
originating from a foreground application (i.e., running 
visibly to the user) was more expected than one from a 
background application. Of the 243 visible permission 
requests that we asked about in our exit survey, partic¬ 
ipants were able to correctly identify the requested per¬ 
mission 44% of the time, and their average rating on our 
expectation scale was 3.4. On the other hand, partic¬ 
ipants were able to correctly identify the resources ac¬ 
cessed by background applications only 29% of the time 
(52 of 180), and their average rating on our expectation 
scale was 3.0. A Wilcoxon Signed-Rank test with con¬ 
tinuity correction revealed a statistically significant dif¬ 
ference in participants’ expectations between these two 
groups (V= 441.5, p<0.001). 

Effects of Visibility on Blocking: Participants were 
willing to block 71 (29% of 243) permission requests 
originating from applications running in the foreground, 

3 Both measures were normally distributed. 


whereas this increased by almost 50% when the applica¬ 
tions were running in the background invisible to them 
(43% of 180). To examine whether invisible requests 
were more likely to be blocked, we calculated the per¬ 
centage of denials for each participant, for both visible 
and invisible requests. A Wilcoxon Signed-Rank test 
with continuity correction revealed a statistically signifi¬ 
cant difference (V=58, p<0.001). 


Effects of Privacy Preferences on Blocking: Partici¬ 
pants completed a combination of Buchanan et al.’s Pri¬ 
vacy Concerns Scale (PCS) © and Malhotra et al.’s 
Internet Users’ Information Privacy Concerns (IUIPC) 
scale 1311. A Spearman’s rank test yielded no statisti¬ 
cally significant correlation between their privacy pref¬ 
erences and their desire to block permission requests 
(p =0.156, p<0.364). 


Effects of Expectations on Blocking: We examined 
whether participants’ expectations surrounding requests 
correlated with their desire to block them. For each par¬ 
ticipant, we calculated their average Likert scores for 
their expectations and the percentage of requests that 
they wanted to block. Pearson’s product-moment test 
showed a statistically significant correlation (r=-0.39, 
p<0.018). The negative correlation shows that partici¬ 
pants were more likely to deny unexpected requests. 


5.3 User Inactivity and Resource Access 

In the second part of the exit survey, participants an¬ 
swered questions about 10 resource requests that oc¬ 
curred when the screen was off (not in use). Overall, 
they were more likely to expect resource requests to oc¬ 
cur when using their devices (p = 3.26 versus p = 2.66). 
They also stated a willingness to block almost half of 
the permission requests (49.6% of 250) when not in use, 
compared to a third of the requests that occurred when 
using their phones (35.2% of 423). However, neither of 
these differences was statistically significant. 

6 Modeling Users’ Decisions 

We constructed several statistical models to examine 
whether users’ desire to block certain permission re¬ 
quests could be predicted using the contextual data that 
we collected. If such a relationship exists, a classifier 
could determine when to prompt users about potentially 
unexpected permission requests. Thus, the response vari¬ 
able in our models is the user’s choice to block the given 
permission request or not. Our predictive variables con¬ 
sisted of the information that might be available at run¬ 
time: permission type, requesting application, and visi¬ 
bility of that application. We constructed several mixed 
effects binary logistic regression models to account for 
both inter-subject and intra-subject correlations. 
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6.1 Model Selection 

In our mixed effects models, permission types and vis¬ 
ibility of the requesting application were fixed effects, 
because all possible values for each variable existed in 
our data set. Visibility had two values: visible (the user 
is interacting with the application or has other contextual 
cues to know that it is running) and invisible. Permission 
types were categorized based on Table[5] The application 
name and the participant ID were included as random ef¬ 
fects, because our survey data did not have an exhaustive 
list of all possible applications a user could run, and the 
participant has a non-systematic effect on the data. 

Table [6] shows two goodness-of-fit metrics: the Akaike 
Information Criterion (AIC) and Bayesian Information 
Criterion (BIC). Lower values for AIC and BIC repre¬ 
sent better fit. Table [6] shows the different parameters 
included in each model. We found no evidence of inter¬ 
action effects and therefore did not include them. Visual 
inspection of residual plots of each model did not reveal 
obvious deviations from homoscedasticity or normality. 


Predictors 

AIC 

BIC 

Screen State 

UserCode 

490.60 

498.69 

Screen On 

Application 

545.98 

554.07 

Screen On 

Application 

UserCode 

491.86 

503.99 

Screen On 

Permission 

Application 

UserCode 

494.69 

527.05 

Screen On 

Visibility 

Application 

UserCode 

481.65 

497.83 

Screen On 

Permission 

Visibility 

Application 

UserCode 

484.23 

520.64 

Screen On 

UserCode 

245.13 

252.25 

Screen Off 

Application 

349.38 

356.50 

Screen Off 

Application 

UserCode 

238.84 

249.52 

Screen Off 

Permission 

Application 

UserCode 

235.48 

263.97 

Screen Off 


We initially included the phone’s screen state as another 
variable. However, we found that creating two separate 
models based on the screen state resulted in better fit than 
using a single model that accounted for it as a fixed ef¬ 
fect. When the screen was on, the model including ap¬ 
plication visibility and application name, while control¬ 
ling for subject effects, offered the best fit. Here, fit 
improved once permission type was removed from the 
model, which shows that the decision to block a particu¬ 
lar permission type changes based on contextual factors. 
When the screen is off, however, the effect of permission 
type was relatively stronger. Similarly, the strong subject 
effect in both models indicates that these decisions are 
highly nuanced from one user to the next. As a result, 
any classifier developed to automatically decide whether 
to block a permission at runtime (or prompt the user) will 
need to be tailored to that particular user’s needs. 

6.2 Predicting User Reactions 

Using these two models, we built two classifiers to make 
decisions about whether to block any of the sensitive per¬ 
mission requests listed in Table[5] These corresponded to 
1.3M requests in our logs. We used our exit survey data 
as ground truth, randomly partitioning it into five groups, 
which we used for 5-fold cross-validation. We used four 
groups for training and one for evaluation. We iterated 
over the entire process 5 times and therefore report the 
averages over these 5 iterations. 

We calculated the receiver operating characteristic 
(ROC) to capture the tradeoff between true-positive and 
false-positive rate. The quality of the classifier can be 
quantified with a single value by calculating the area un¬ 


Table 6: Goodness-of-fit metrics for various mixed ef¬ 
fects logistic regression models on the exit survey data. 


der its ROC curve (AUC) |23j |. The closer the AUC gets 
to 1.0, the better the classifier is. The AUC for a random 
classifier is 0.5. When screens were on, the AUC was 0.7, 
which is 40% better than the random baseline, making it 
a fair classifier. When screens were off, the AUC was 
0.8, which is 60% better than a random baseline, making 
it a good classifier. 

We ran the classifier on the log files we gathered from 
users and had it predict the portion of sensitive requests 
that users might want to block. When phone screens 
were on, the model predicted that participants would 
have blocked 35.29% of sensitive requests, blocking an 
average of 645 requests daily. When screens were off, the 
classifier predicted 35.1% of requests would have been 
blocked (1,143 requests per user/day). 


7 Discussion 

We observed that in one week of standard smartphone 
usage, 80% of our participants deemed at least one per¬ 
mission request as being inappropriate. This violates 
Nissenbaum’s notion of “privacy as contextual integrity” 
because applications were performing actions that defied 
users’ expectations |33| . Felt et al. posited that users 
may be able to better understand why permission re¬ 
quests are needed if some of these requests are granted 
via runtime consent dialogs, rather than Android’s cur¬ 
rent install-time notification approach 1141. By granting 
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permissions at runtime, users will have additional con¬ 
textual information; based on what they were doing at 
the time that resources are requested, they may have a 
better idea of why those resources are being requested. 
We make two primary contributions that system design¬ 
ers can use to make more usable permissions systems: 
we show that runtime notifications need to be tailored 
to individual users’ needs and that platforms need to ac¬ 
count for whether an application’s access to protected re¬ 
sources is obvious to the user. 

Based on the frequency with which potential runtime 
permissions are requested (Section |4|, it is infeasible 
to prompt users each and every time. Doing so would 
quickly overwhelm them and lead to habituation. Yet at 
the same time, drawing user attention to the situations 
in which they are likely to be concerned will lead to 
greater control and awareness. Thus, the challenge is 
in automatically inferring when users are likely to find 
a permission request unexpected, and then only prompt¬ 
ing them in these cases. Based on our data, we observed 
that participants’ desires to block particular permissions 
were heavily influenced by two main factors: their un¬ 
derstanding of the relevance of a permission request to 
the functionality of the requesting application and their 
individual privacy concerns. 

Our models in Section [6] showed that individual charac¬ 
teristics greatly explain the variance between what dif¬ 
ferent users deem appropriate, in terms of access to pro¬ 
tected resources. While responses to privacy scales failed 
to explain these differences, this was not a surprise, as the 
disconnect between stated privacy preferences and be¬ 
haviors is well-documented (e.g., [ lj). This means that 
in order to accurately model user preferences, the sys¬ 
tem will need to learn what a specific user deems in¬ 
appropriate over time. Thus, a feedback loop is likely 
needed: when devices are “new,” users will be required 
to provide more input surrounding permission requests, 
and then based on their responses, they will see fewer 
requests in the future. While we documented the fre¬ 
quency with which protected resources were accessed, 
future work is needed to quantify the varying contexts 
in which it can occur. Specifically, habituation could be 
drastically reduced (i.e., fewer runtime prompts) if users 
are only asked for permission for unique combinations of 
application, resource, and context. Future work is needed 
to quantify the varying contexts, as they are likely to be 
much more complex than “foreground vs. background 
application” or “screen on vs. screen off.” 

Beyond individual subject characteristics (i.e., personal 
preferences), participants based their decisions to block 
certain permission requests on the specific applications 
making the requests and whether they had contextual 


cues to indicate that the applications were running (and 
therefore needed the data to function). Future sys¬ 
tems could take these factors into account when decid¬ 
ing whether or not to draw user attention to a partic¬ 
ular request. For example, when an application that a 
user is not actively using requests access to a protected 
resource, she should be shown a runtime prompt. If 
she decides to grant that request, then that decision is 
likely to hold when she is actively using that same ap¬ 
plication (and therefore a subsequent prompt may not 
be needed). At a minimum, platforms need to treat 
permission requests from background applications dif¬ 
ferently than those originating from foreground applica¬ 
tions. Similarly, applications running in the background 
should use passive indicators to communicate when they 
are accessing particular resources. Platforms can also be 
designed to make decisions about whether or not access 
to resources should be granted based on whether contex¬ 
tual cues are present, or at its most basic, whether the 
device screen is even on. 

Finally, we built our models and analyzed our data within 
the framework of what resources our participants be¬ 
lieved were necessary for applications to correctly func¬ 
tion. Obviously, their perceptions may have been incor¬ 
rect in many cases, such that if they better understood 
why a particular resource was necessary, they may have 
been more permissive. Thus, it is incumbent on develop¬ 
ers to adequately communicate why particular requests 
are necessary, as this greatly impacts user notions of con¬ 
textual integrity. Yet, no mechanisms in Android ex¬ 
ist for developers to do this as part of the permission¬ 
granting process. For example, one could imagine re¬ 
quiring metadata to be provided that explains how each 
requested resource will be used, and then automatically 
integrating this information into permission requests. 
Tan et al. examined a similar feature on iOS that allows 
developers to include free-form text in runtime permis¬ 
sion dialogs and observed that users were significantly 
more likely to grant requests that included this text ED- 
Thus, we believe that including succinct explanations in 
these requests would go a long way towards preserving 
contextual integrity by promoting greater transparency. 

In conclusion, we believe this study was instructive in 
showing the circumstances in which Android permission 
requests are made under real-world usage. While prior 
work has already established that most mobile permis¬ 
sions systems are failing users, we believe our study can 
benefit system designers by demonstrating several ways 
in which contextual integrity can be improved, thereby 
empowering users to make better security decisions. 
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A Invisible requests 

Following list shows the set of applications that have requested most 
number of permissions while executing invisibly to the user and the 
most requested permission types by each respective application. 

• FacebookApp— ACCESS NETWORK STATE, ACCESS FINE 
LOCATION, ACCESS WIFI STATE ,WAKE LOCK, INTER¬ 
NET 

• Google Location— WAKE LOCK, ACCESS FINE LOCATION, 
GET ACCOUNTS, ACCESS COARSE LOCATION, ACCESS 
WIFI STATE 

• Facebook Messenger— ACCESS NETWORK STATE, ACCESS 
WIFI STATE, WAKE LOCK, READ PHONE STATE, INTER¬ 
NET 

• Taptu DJ— ACCESS NETWORK STATE, INTERNET, NFC 

• Google Maps— ACCESS NETWORK STATE, GET AC¬ 
COUNTS, WAKE LOCK, ACCESS FINE LOCATION, INTER¬ 
NET 

• Google (Gapps)— WAKE LOCK, ACCESS FINE LOCA¬ 
TION, AUTHENTICATE ACCOUNTS, ACCESS NETWORK 
STATE, ACCESS WIFI STATE 

• Fouraquare —ACCESS WIFI STATE, WAKE LOCK, ACCESS 
FINE LOCATION, INTERNET, ACCESS COARSE LOCA¬ 
TION 

• Yahoo Weather— ACCESS FINE LOCATION, ACCESS NET¬ 
WORK STATE, INTERNET, ACCESS WIFI STATE, WRITE 
SYNC SETTINGS 

• Devexpert Weather —ACCESS NETWORK STATE, INTER¬ 
NET, ACCESS FINE LOCATION, ACCESS COARSE LOCA¬ 
TION 

• Tile Game(Umoni)— ACCESS NETWORK STATE, WAKE 
LOCK, INTERNET, ACCESS WIFI STATE, WRITE SET¬ 
TINGS 

Following is the most frequently requested permission type by appli¬ 
cations while running invisibly to the user and the applications who 
requested the respective permission type most. 
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• ACCESSS/ETWORKSTATE— Facebook App, Google Maps, 
Facebook Messenger, Google (Gapps), Taptu - DJ 

• WAKESOCK —Google (Location), Google (Gapps), Google 
(GMS), Facebook App, GTalk. 

• ACCESS SINE .LOCATION —Google (Location), Google 

(Gapps), Facebook App, Yahoo Weather, Rhapsody (Music) 

• GET ACCOUNTS —Google (Location), Google (Gapps), 
Google (Login), Google (GM), Google (Vending) 

• ACCESS.WIFI STATE —Google (Location), Google (Gapps), 
Facebook App, Foursqaure, Facebook Messenger 

• UPDATEDEVICESTATS— Google (SystemUI), Google (Loca¬ 
tion), Google (Gapps) 

• ACCESS .COARSE.LOCATION— Google (Location), Google 
(Gapps), Google (News), Facebook App, Google Maps 

• AUTHENTICATE ACCOUNTS —Google (Gapps), Google (Lo¬ 
gin), Twitter, Yahoo Mail, Google (GMS) 

• READ SYNC SETTINGS —Google (GM), Google ( GMS ), an- 
droid.process.acore, Google (Email), Google (Gapps) 

• INTERNET —Google (Vending), Google (Gapps), Google (GM), 
Facebook App, Google (Location) 


B Permission Type Breakdown 

This table lists the most frequently used permissions during the study 
period. 


Permission Type 

Requests 

ACCESS-NETWORK-STATE 

41077 

WAKE-LOCK 

27030 

ACCESS-FINE-LOCATION 

7400 

GET-ACCOUNTS 

4387 

UPDATE_DEVICE_STATS 

2873 

ACCESS _W IF [ _STATF 

2092 

ACCESS-COARSE-LOCATION 

1468 

AUTHENTICATE .ACCOUNTS 

1335 

READ-SYNC_SETTINGS 

836 

VIBRATE 

740 

INTERNET 

739 

READ-SMS 

611 

READ-PHONE-STATE 

345 

STATUS _BAR 

290 

WRITE-SYNC-SETTINGS 

206 

CHANGE-COMPONENT-ENABLED-STATE 

197 

CHANGE-WIFLSTATE 

168 

READ-CALENDAR 

166 

ACCOUNT JMANAGER 

134 

ACCESS_ALL-DOWNLOADS 

127 

READ-EXTERNAL-STORAGE 

126 

USE-CREDENTIALS 

101 

READ-LOGS 

94 

WRITE-SMS 

62 

WRITE_CALENDAR 

60 

Bluetooth 

60 

CONNECTIVITY-INTERNAL 

58 

STATUS _BAR_SERVICE 

57 

READ-SYNC-STATS 

56 

NFC 

51 

WRITE_SETTINGS 

50 

WRITE-EXTERNAL-STORAGE 

48 

PACKAGE-USAGE-STATS 

28 

SUBSCRIBED _FEEDS_READ 

24 
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C User Application Breakdown 

This table shows the applications that most frequently requested access 
to protected resources during the study period. 


Application Name 

Requests 

facebook.katana 

40041 

google.process.location 

32426 

facebook.orca 

24702 

taptu. streams 

15188 

google.android.apps.maps 

6501 

google.process.gapps 

5340 

yahoo.mobile.client.android. weather 

5505 

tumblr 

4251 

king.farmheroessaga 

3862 

joelapenna.foursquared 

3729 

telenav.app.android.scout us 

3335 

devexpert. weather 

2909 

ch.bitspin.timely 

2549 

umonistudio.tile 

2478 

king.candycrushsaga 

2448 

android. sy s temui 

2376 

bambuna.podcastaddict 

2087 

contapps. android 

1662 

handcent.nextsms 

1543 

foursquare.robin 

1408 

qisiemoji.inputmethod 

1384 

devian.tubemate.home 

1296 

google.android.gm 

1180 

lookout 

1158 

aol.mobile.aim 

1125 

google. android .music: main 

1114 

rhapsody 

1074 

google.android.gms 

1021 

yahoo.mobile.client.android. 

fantasyfootball 

886 

jb.gosms 

755 

google.android.googlequicksearchbox 

711 

android.mms 

695 

ideashower.readitlater.pro 

672 

android.inputmethod.latin 

672 

google.android.gsf.login 

618 

pandora.android 

611 

google. android. apps .plus 

582 

andrewshu.android.reddit 

569 

tunein.player 

556 

airkast.KNBRAM 

546 

twitter, android 

523 

android.vending 

486 

yahoo.mobile.client.android.mail 

480 

sg.gumi.bravefrontier 

473 

yahoo.mobile.client.android.yahoo 

458 

nuance, swype. trial 

402 

viber.voip 

392 

zynga. words 

388 

touchtype.swiftkey 

377 


D Distribution of Requests 

The two graphs shows the distribution of number of requests per day 
per user and the distribution of request for a given day. First graph 
shows the distribution of requests through out a given day averaged 
across the data set and second graph shows the distribution of number 
requests across days for each user. 



Hour of the day 
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